- 31 mars 2021

Nyhetsbrev OT-Säkerhet #25 - Giganter och Konsekvenser

Ett sprängfyllt nyhetsbrev som den här gången förbereder en kamp mellan två giganter, ger ett boktips om konsekvensdrivet säkerhetsarbete, tycker lite synd om Rockwell Automation, diskuterar konceptet "Insecure by design", ger en lång rad spännande lästips och en massa annat!

Nyhetsbrev nummer 25! Något av ett jubileum alltså... Det första nyhetsbrevet skickade jag till fyra läsare. Tydligen fanns det ett och annat intressant bland mina tankar för nu är det flera hundra gånger fler som läser varje utgåva. Det är fantastiskt roligt med ett så positivt gensvar och jag vill verkligen skicka ett stort tack till dig som läser mina spretiga funderingar kring det här spännande ämnet!

Om det är första gången du läser ett av mina nyhetsbrev kanske du undrar vad det där "OT" är som jag pratar om? OT står för Operational Technology vilket är ett syskon till IT, Information Technology. Med IT använder man teknik för att hantera information. Inom OT använder man liknande teknik men för "Operations", alltså att få fysiska saker under kontroll. Det kan exempelvis vara att styra maskiner i en fabrik, elproduktionen i ett kraftverk eller kemiska processer i ett raffinaderi. Inom IT är fokus ofta på att skydda hemligheter men inom OT blir det oftast viktigast att hålla en funktion tillgänglig och korrekt. Det innebär att säkerhetsarbetet kommer se väldigt annorlunda ut, vilket är anledningen till mina texter.

Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. Som vanligt vill jag gärna att du delar med dig av nyhetsbrevet till kollegor som kan vara intresserade! Ju fler som läser, desto bättre möjligheter får jag att producera bra innehåll framöver! Om du vill ha nyhetsbrevet i inkorgen i fortsättningen är det bara att dra ett mejl till mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta!

Du hittar alla tidigare utgåvor av nyhetsbrevet på www.ot-säkerhet.se. När det kommer nytt material så annonserar jag det på en massa ställen: min Linkedin-profil, i en egen LinkedIn grupp, i Facebook-gruppen Säkerhetsbubblan, på Twitter och på en egen Facebook-sida. Du kan också prenumerera via RSS på www.ot-säkerhet.se. Framöver kommer också en kopia publiceras på Ateas officiella blogg.

Ge mig gärna mothugg, frågor eller förslag på LinkedIn där den här utgåvan delades. Tänk på att du kan hjälpa mig, mer än du kanske tror, genom att trycka "like" på den här artikeln och genom att dela den vidare. Tack för hjälpen!

Så olika men ändå så lika!

Något jag slås av varje gång jag träffar nya verksamheter för att prata säkerhet är hur olika de ser ut på ytan, men hur mycket som går igen när man tittar innanför skalet! Ett sågverk kan väl inte ha mycket gemensamt med tillverkning av biogas? Hur kan en industrihamn vara besläktad med eldistribution? Man kan tycka att skyddet av medicintekniska system i sjukvården inte borde ha jättemycket att göra med en högteknologisk tillverkande industri men de har de! De har olika namn på saker och de har lite olika prioriteringsmetoder men de är alla ute efter att skydda fysiska funktioner från störningar och ganska ofta också att människor skyddas från att skadas fysiskt på grund av manipulerade eller störda OT-system. Miljöpåverkan är också ofta en risk som har stort fokus.

En annan likhet mellan just sjukvård och hitech-tillverkning är att de både måste skydda väldigt känslig information i sina OT-system och se till att systemen i sig fungerar exakt som det är tänkt. I riskanalyserna hamnar man ofta på väldigt låga sannolikheter och extrema konsekvenser vilket ju kan kräva ett lite speciellt synsätt. Just detta är temat för mitt boktips lite längre ner där en väldigt intressant metod beskrivs.

I förra nyhetsbrevet frågade jag om intresset för någon form av nätverkande eller onlineforum kring OT-säkerhet. Av svaren att döma verkar det glädjande nog som att intresset är stort. Jag tror just att mötet mellan människor från olika branscher som alla har ett intresse av OT-säkerhet kan bli riktigt spännande och roligt tack vare de oväntade likheterna mellan deras utmaningar!

Det visade sig att mina tankar på någon form av diskussionsforum kring OT-säkerhet sammanföll med Karl Emil Nikkas tankar om något motsvarande fokuserat på IT- och informationssäkerhet. Du är kanske med i gruppen Säkerhetsbubblan på Facebook som han ligger bakom tillsammans med Jonas Lejon? Vi insåg direkt att det är bäst för alla om vi skapar ett gemensamt ställe att diskutera alla former av säkerhetsfrågor. Herr Nikka hade redan kommit en bra bit på väg i sina planer så då väljer jag att skrota mina egna planer och lägger min energi på att stötta honom i arbetet för en gemensam plats. Vi återkommer framöver med mer information...

Intresset för att träffas och diskutera OT-säkerhet var också stort. Fysiska träffar avvaktar jag förstås lite för att se hur det går med pandemin. Någon form av digital träff skulle det däremot kunna bli framöver. Clubhouse hade ju kanske varit ett kul upplägg. Jag tar gärna emot förslag och tankar på former, teman och metoder! Om någon har en Clubhouse-inbjudan att skicka till mig så tar jag den gärna, måste bara skaffa en äpple-telefon också...

För någon vecka sedan skapade jag en omröstning på LinkedIn om vilka delar av nyhetsbrevet som mina läsare vill se mer av. (Det är inte försent, tyck gärna till fortfarande!) Det verkar så här långt vara många som gillar dagens upplägg men med önskemål om att "Mats Filosoferar" ska ta lite större utrymme och även mina tankar kring aktuella händelser. Jag kommer förstås ta till mig önskemålen framöver!

Giganternas kamp!

Det är verkligen ingen hemlighet att jag tycker det är roligt att jag stöter på så mycket spännande teknik i mitt arbete. Nu måste jag säga att det är två ovanligt coola prylar som står i labbet och väntar på sin tur. Jag kan riktigt höra hur de frustar och stampar i marken som de båda fullblod de är.

I den ena ringhörnan står en maskin som jag har nämnt i tidigare nyhetsbrev. Det är Pro-versionen av IPSen från TxOne, kallad "EdgeIPS Pro". De har tagit deras lilla ruggade OT-IPS som du kan läsa mer om i nyhetsbrev #23 och gjort en datacenter-version som innehåller 24 stycken separata IPS-segment! Dessutom har de kryddat anrättningen med en del extra funktionalitet. Det här är 16 kg brutal OT-IPS som i princip ska klara att maxa alla 24 Gigabit segmenten samtidigt! Det finns faktiskt en dubbelt så stor maskin också, men den har jag inte lyckats få fingrarna på ännu... Ett typiskt use-case för Pro-versionen är när man inte vill bygga in de små EdgeIPS-enhetern från TxOne i respektive maskin som ska skyddas utan hellre samlar skyddet i ett nätverksrum eller datacenter. Ett extra tack till TxOne som skickade den första Pro-burken i Norden direkt till mig! Det här ska bli riktigt roligt!

I den andra ringhörnan står en riktig doldis för de flesta. Det är en "ixia PerfectStorm One" från Keysight. Keysight har jag nämnt tidigare, exempelvis deras fina lilla tap "IxTap" i nyhetsbrev 17. Den ser ärligt talat inte så mycket ut för världen, men specen säger någonting helt annat! Tanken med den här besten är att skapa verklighetstrogen testtrafik för att provskjuta mot olika typer av nätverkssäkerhetsutrustning. I den här kör man en programvara kallad "BreakingPoint" vilket är ett mycket passande namn... Genom de 8 portarna med SFP+ kan du skapa och pressa igenom 80 Gb/s av testtrafik. Det är dessutom inte vilken testtrafik som helst utan du kan krydda med mängder av attacker och skadlig kod. I det enorma biblioteket med elakheter finns en rejäl dos OT-specifika attacker att välja från. Det typiska use-caset är att simulera trafik för exempelvis en brandvägg genom att helt enkelt stadigt öka på med trafik tills brandväggen inte klarar mer och kastar in handduken!

De här två tänkte jag matcha mot varandra framöver. Det kommer bli en intressant match mellan två riktiga tungviktare! Vi får hoppas att propparna och luftkonditioneringen håller för det kommer bokstavligen gå hett till! Vadslagning på vinnaren, någon?

"Ooops!" eller "Insecure by design"

Nyligen fick amerikanska automations-giganten Rockwell Automation (mest kända för varumärket Allen-Bradley) ett delikat problem kring en sårbarhet i en låååång radda av deras Logix-controllers. Sårbarheten fick dessutom CVSS-poäng 10, dvs den absolut värsta graderingen en sårbarhet kan få. Med tanke på att det var en bugg som gjorde det enkelt att helt ignorera alla former av inloggningskrav i produkterna var betyget kanske inte så förvånande. Det blev inte bättre när Rockwell några dagar senare tvingades annonsera att problemet inte skulle gå att lösa med en patch!

Det är inte klart för mig ännu varför sårbarheten inte går att adressera med en patch, spontant är den enda förklaringen att sårbarheten på något vis är kopplad till hårdvaran - vilket låter osannolikt. Vi får se hur den här historien utvecklar sig...

Jag hade egentligen tänkt att skriva en liten text om begreppet "Insecure by design" vilket INTE ALLS avser det som Rockwell råkade ut för, alltså produkter som designats lite tokigt och därmed är osäkra. Det här är ett begrepp som blivit populärt under senaste halvåret i diskussioner kring hur vi bygger våra automationssystem. Jag har hört lite olika varianter men min egen tolkning är att "insecure by design" avser faktumet att många komponenter och protokoll inte behöver "hackas" för att manipuleras - de är helt enkelt utformade för att göra som de blir åtsagda, oavsett vem det är som skickar ordern.

Det låter som ett lite löjligt resonemang men det är förvånansvärt ofta man springer på situationer när någon är upprörd över att de hittat ett opatchat system och hävdar att det är ett hot mot verksamheten. Om det råkar vara ett system som är "Insecure by design" pekar man då på faktumet att, även om systemet var helt uppdaterat, så kör det en mjukvara som inte behöver hackas för att en angripare ska manipulera den fysiska processen. Allt man behöver finns till och med beskrivet i manualen!

Nu var det som sagt inte det här som Rockwell drabbades av även om effekten i slutändan blev den samma. Sista ordet är inte sagt kring vare sig deras sårbarhet eller hur man ska värdera sårbarheter i OT-system...

Konsekvensdrivet säkerhetsarbete - Ett boktips!

Som jag teasade om i förra nyhetsbrevet så kommer här en berättelse om vad jag lärt mig av boken "Security PHA Review for Consequence-Based Cybersecurity" och något slags recension av boken.

Boken gör en grundlig genomgång av SPR-metoden på cirka 140 sidor och gör det på ett sätt som känns lättillgängligt för de flesta läsare. SPR, som ska uttalas som det engelska ordet "Spur", syftar till att flytta fokus inom OT-säkerhetsarbetet bort från att skydda varje komponent och istället fokusera på att göra den fysiska processen "ohackbar" och därmed säker. (SPR är en förkortning av "Security PHA Review".)

Det är viktigt att ha med sig att det man vill uppnå med SPR är framför allt att säkerställa att vi inte har ihjäl folk, skadar miljön eller orsakar stora fysiska skador som är svåra och dyra att åtgärda. Därför är det en metod som framför allt passar i processindustrier och då speciellt i verksamheter som har farliga moment i sin produktion.

Eftersom man utgår från processen i den inledande riskanalysen, istället för att göra det som ISA/IEC 62443 kallar "en riskanalys på hög nivå", så identifierar man mycket lättare de ställen där skydd av OT-systemen kan göra verklig nytta för skyddet av processen. På samma sätt påpekar de att det som 62443 kallar "detaljerad riskanalys" inte alls är en riskanalys utan snarare en granskning av den design som tagits fram. Det här angreppssättet tar hand om ett av de områden som alltid stört mig i 62443-standarden och gör det på ett riktigt elegant sätt. Jag hoppas att få omsätta det här arbetssättet i ett verkligt projekt snart, det ska bli intressant! Man inser att man är en riktig nörd när man går igång på sådana här insikter...

Författarna sågar ett antal andra metoder, som till namnet verkar vara ungefär samma sak, vid fotknölarna. Metoder som "Cyber PHA", "Cyber HAZOP" och "CHAZOP" siktar i praktiken på något helt annat och liknar egentligen mer feleffektsanalys (FMEA, "Failure Mode and Effects Analysis"). De har alla sin plats men med andra syften.

Det som jag kanske gillar allra mest med SPR är att man tar ett rejält kliv bort från skogen och då plötsligt kan se träden. Andra verktyg tenderar ofta att bli väldigt detaljfokuserade, tekniska och omständliga men missar ironiskt nog det egentliga målet att skapa en översiktlighet av risker och hot. Man försöker göra något åt vartenda träd i hela skogen i förhoppningen att skogen borde bli bättre. I SPR börjar vi med att titta på skogen för att sedan välja vilka träd som är viktigast att göra någonting åt.

Tidigt i boken gör de upp med några av de (som jag tycker) mest störande bristerna som man stöter på i "klassisk" analys av sårbarheter och risker. De hävdar (och jag håller med) att:

Att en säkerhetsbrist i sig inte har någon konsekvens förrän någonting händer som gör att bristen påverkar processen. Ett trasigt bilbälte får ingen konsekvens förrän man krockar.
Eftersom det finns så många konsekvenser av varje sårbarhet blir det omöjligt att veta vilka konsekvenser som inte kan uppstå eftersom de förhindras av någon helt annan säkerhetsfunktion eller någon begränsning i den fysiska processen. I en bil som bara går att köra i 5 km/h kanske ett trasigt bilbälte inte är ett problem men hur vet du bilens maxfart om du bara tittar på skyddet av föraren?
Eftersom det nästan alltid finns massor med tänkbara konsekvenser av en sårbarhet blir sårbarheten också omöjlig att bedöma. Ett stulet lösenord kan användas på extremt många olika sätt, men vilka är värst och vad betyder det för risken av händelsen "Stulet lösenord"? Man tvingas ofta använda något slags påhittat värsta scenario.
I många metoder är sannolikhet eller frekvens en viktig faktor för riskbedömningen vilket sällan är en meningsfull bedömningsgrund. Hur bedömer du sannolikheten för att en hacker lyckas hacka just ditt system? Hur ofta det har skett historiskt? Kommer de verkligen ge upp om de misslyckas i de första 20 försöken? Sannolikheter fungerar bra för slumpmässiga händelser men är väldigt mycket sämre för beslutsamma och medvetna mänskliga angripare.

Just alla de där godtyckliga sannolikhetsbedömningarna som görs är nog den största anledningen till att jag genomlidit så många meningslösa workshops för riskanalyser. Ett annat alternativ som fungerar i många viktiga situationer är att använda kvantitativa metoder. Men det är en annan historia som har sitt eget existensberättigande. Vill du läsa mer så har jag skrivit om det i Nyhetsbrev #16.

SPR-metoden bygger på att det redan finns någon form av PHA- eller HAZOP-liknande analys som man återanvänder genom att ta alla felscenarier och skydd från den och utökar dem med bedömningar av deras "hackbarheten" . Om man inte har sådana analyser får man helt enkelt göra det som en del av SPR-arbetet. Enkelt uttryckt kan man säga att en HAZOP-analys är ett systematiskt sätt för en grupp experter att identifiera alla sätt saker kan gå snett oavsett orsak och vilka skydd som finns för att motverka att farliga situationer uppstår. Om man ska summera vad SPR-metoden lägger till på ett extremt komprimerat sätt så blir det:

För varje källa till avvikelser i processen analyserar man om den går att provocera fram genom att hacka en utrustning. Är den inte hackbar så är inte scenariet hackbart. (Här har jag en viktig invändning mot författarnas resonemang, se nedan.)
Om källan är hackbar tittar man på de skydd som finns i processen. Om något av dem inte är hackbart så antas de skyddet motverka avvikelsen och därmed är scenariet inte heller hackbart. (Även här har jag invändningar, se nedan.)
Om både källan och alla skydd är hackbara blir hela scenariet hackbart och då måste man hitta åtgärder. Åtgärderna kan bestå i att införa icke hackbara skydd eller att man höjer säkerhetsnivån i systemet. (Man använder då begreppet SL-T från ISA/IEC 62443, "Security Level Target".)
Repetera för alla system och zoner. Sammanställ resultatet för helheten. Inför åtgärderna som identifierats.

Vad är det då för invändningar jag har? Ja, det är faktiskt flera stycken...

Enligt boken måste en hackbar komponent gå att nå med ett routbart nätverksprotokoll. I min värld så kan man mycket väl manipulera ett system även om det inte går att komma åt det, om det är möjligt att manipulera dess programmering utan att det upptäcks. I min erfarenhet är ofta utvecklingsmiljöer mindre skyddade än de system dit programvaran sedan flyttas. Man kan också vända sig mot att de kräver routbarhet eftersom det i så fall missar situationer där man hoppar mellan system med någon form av direktanslutning emellan dem.
Författarna kräver att källan till en avvikelse ska vara hackbar för att scenariet ska vara relevant. För en angripare som har mycket tid kan det mycket väl räcka med att sabotera ett eller flera skydd och sedan bara vänta på att processen får en avvikelse "av sig själv".
SPR-metoden säger att händelser och skydd som hanteras av människor inte är hackbara vilket i så fall ignorerar möjligheterna till "Social Engineering".
Boken tar inte upp situationer där det av någon anledning finns krav på redundanta skydd. I sådana fall måste man ju förstås ta hänsyn till att det finns redundans bland de icke-hackbara skydden.

Nu låter det som att jag sågar både boken och SPR-metoden rejält men så är det faktiskt inte. De lämnar öppningar för att skapa sin egen version av metoden som passar den egna verksamheten och dess industrityp. Vad som är acceptabelt och relevant får man avgöra själv med någon form av risk- och konsekvensanalys. Självklart måste arbetsmetoder och kravnivåer rimligen skilja mellan ett kärnkraftverk och en fabrik som tillverkar tandpetare...

Som du (förhoppningsvis) ser i min beskrivning av SPR-metoden så letar man efter sårbarheter i den fysiska processen istället för i enskilda komponenter och man tittar enbart på konsekvenserna av olika scenarier. Sannolikheter dyker aldrig upp i resonemanget och mikroprocessorbaserade system betraktas som hackbara oavsett om de faktiskt har några sårbarheter eller inte. Och häri ligger metodens finess, fokus ligger på att helt bygga bort möjligheten för allvarliga konsekvenser att inträffa även om varenda system blir hackat...

Om man ska knyta tillbaka till mitt filosoferande i förra nyhetsbrevet så får vi en chans att låta skyddet av processen verkligen kravställa skyddet av systemen, precis på det sätt som skyddet av informationen ska ställa krav på skydd av IT-system!

Sammantaget kan jag verkligen rekommendera både boken och SPR-metoden.

Metoden passar inte för alla typer av verksamheter men rätt använd och anpassad så tar den hand om en hel del störande moment i ISA/IEC 62443 standarden och flyttar fokus från att minska sannolikheter till att minska konsekvenser.

Har din organisation redan bra koll på processäkerheten generellt sett (oavsett om det just är en klassisk HAZOP-metodik eller något annat) blir införandet av SPR inte någon omfattande sak att få till!

Var annonseras sårbarheteter?

Jag fick frågan om var man ska söka eller prenumerera på sårbarhetsannonseringar för OT. Personligen använder jag oftast amerikanska CISAs ICS-CERT: https://us-cert.cisa.gov/ics/advisories. För generella sökningar i kända sårbarheter är https://www.cvedetails.com/ alltid en bra källa.

Gäller det en speciell tillverkare så är förstås deras egen annonsering viktig men där kan det vara lite olika spelregler beroende på om du har aktiva serviceavtal med dem.

Jag söker mer OT-utrustning!

Jag har ett litet OT-labb där jag konfigurerar och testar OT-säkerhetsutrustning för Nyhetsbrevet. Nu vill jag utvidga och bredda labbet och därför söker jag samarbeten med tillverkare och distributörer av intressant OT-utrustning för samarbete, lån eller köp av utrustning under "Not For Resale"-vilkor. Jag tänker mig allt från PLCer och IO-enheter till strömförsörjning, sensorer och HMI-paneler men även ren nätverksutrustning. Färdiga utbildnings- eller demonstrationsuppsättningar är också intressanta! Även begagnad utrustning som någon läsare har över är intressant.

Hör av er! mats.karlsson-landre@atea.se.

Lästips!

https://www.sakerhetspolisen.se/publikationer/om-sakerhetspolisen/sakerhetspolisen-2020.html SÄPOs årsbok för 2020 släpptes i mitten av Mars och innehåller väldigt mycket intressant. Jag håller verkligen med om att de stora bristerna inom säkerhetsskyddsområdet är oroande, inte minst inom många kritiska OT-verksamheter!

https://www.regeringen.se/rattsliga-dokument/lagradsremiss/2021/03/ett-starkare-skydd-for-sveriges-sakerhet/ Det var självklart ingen slump att Justitidepartementet släppte ett förslag till stärkt säkerhetsskydd dagen efter att SÄPO släppte sin årsbok. En mer framträdande roll för säkerhetsskyddschefer, säkerhetsskyddsavtal i fler situationer, bättre analyser av utkontraktering och större befogenheter för tillsynsmyndigheterna, låter alla som bra förslag! Kim Hakkarainen sammanfattar det bra här: https://blogg.mrpoyz.net/paradigmskifte/

https://www.fra.se/download/18.15d6ea201729ce403d2358/1615817255659/FRA-arsrapporten-for-2020.pdf När du ändå är igång så kom FRAs årsrapport samma vecka...

https://download.schneider-electric.com/files?p_enDocType=White+Paper&p_File_Name=998-21085205_CybersecurityBusinessContinuity_GMA_whitepaper.pdf&p_Doc_Ref=998-21085205_GMA Ett intressant papper från SchneiderElectric som tittar på konsekvenserna av att inte ha med cybersäkerhetsåtgärder i sin krisplanering. Man använder pandemin som exempel för att illustrera hur OT-hoten påverkas av kriser i samhället eller någon annan övergripande händelse.

https://hub.dragos.com/hubfs/Whitepaper-Downloads/Industrial-Cyber-Risk-Management-2021March.pdf Dragos tankar kring hur man ska bedriva risk management inom industrin. En del nya synsätt som jag gillar.

https://www.pull-the-plug.net/thesis/ Avhandling av Jan Hoff från universitetet i tyska Hagen som föreslår en metod för att automatiskt skapa attackgrafer för OT baserat på "MITRE ATT&CK for ICS".

https://www.splunk.com/en_us/blog/security/splunk-for-ot-security-v2-soar-and-more.html Splunk gör intressanta saker för att OT ska fungera bättre i klassiska SIEM-lösningar, något som många upplever som ett problem idag.

https://www.willistowerswatson.com/en-US/Insights/2021/03/cyber-risk-and-critical-infrastructure Ett papper kring hur dagens IT-försäkringar bör närma sig OT-världen. Man kan ha många åsikter om försäkringars värde så lär dig mer!

https://www.linkedin.com/pulse/legacy-system-problem-keeps-growing-dale-peterson De senaste veckorna har det nästan blivit bråk kring frågan om "insecure by design" i komponenter närmast våra processer. Här är ett av Dale Petersons inlägg om saken och här är ett par inlägg av Joe Weiss som har en annan åsikt: https://www.controlglobal.com/blogs/unfettered/observations-from-the-2021-sans-ics-cyber-security-conference/ och https://www.controlglobal.com/blogs/unfettered/lack-of-authentication-of-process-sensors-does-not-appear-to-bother-people/

https://www.txone-networks.com/upload/website/white_papers/normal/Network%20Segmentation%20-%20The%20OT%20Standard%20for%20Industry%204.0_20120818233.pdf Klokskaper kring segmentering och närbesläktade ämnen från TxOne som förstås är lite skruvade mot deras egna produkter men ändå har en del grundläggande guldkorn!

https://www.ncsc.gov.uk/blog-post/what-is-ot-malware Genomgång av skadlig kod i OT-världen från brittiska NCSC som alltid levererar stabilt material.

https://webbutik.skr.se/bilder/artiklar/pdf/7585-871-5.pdf Sveriges Kommuner och Regioner har tillsammans med Offentliga Fastigheter gett ut ett gediget material kring digital fastighetsautomation som pratar flitigt om säkerhetsaspekterna i detta spännande OT-område.

https://www.missionsecure.com/blog/industrial-cybersecurity-applying-zero-trust-and-carta-to-operational-technology-ot Några intressanta reflektioner kring kopplingen mellan "Zero Trust" och OT-Säkerhet samt hur man knyter ihop det med CARTA.